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UNITED STATES PATENT APPLICATION 


of 


JEFFREY DELANEY 
WILLIAM H. KIRTLEY 
ROBERT KUSZEWSKI 
JOHN ANDREW LASH 
ROBERT MATHEWS 

DAVID PAGE 
MARTIN SARABURA 
and 

GREGORY WARDEN 


for 


APPLICATION PROGRAM INTERFACE FOR 
MESSAGE ROUTING AND MANAGEMENT SYSTEM 


RELATED APPLICATION 


This application claims the benefits of U.S. Provisional Application 
Serial No. 60/189,145, filed on March 14, 2000. 


FIELD OF THE INVENTION 

The present invention relates to communication services, and in 
particular to delivery of messages to selected recipients through one or more 
specified communication modes. 


10 BACKGROUND OF THE INVENTION 

Thanks to improvements in technology and widespread consumer 
interest, once-exotic forms of communication have become commonplace, 
and today the average consumer has access to a broad array of 
communications services. The Internet and wireless telephony, once the 
1 5 preserve of an elite few, now routinely supplement traditional telephone 

services and are frequently supplied by the same carriers. Even inexpensive 
home computers now include facsimile capability. Businesses employing 
mobile employees can furnish them with economical pagers that incorporate 
advanced features, such as text transmission and Internet access. 
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The sheer proliferation of communication options, while greatly 
improving access and convenience, has engendered problems as well. The 
existence of a communication channel does not ensure that the recipient of a 
message will be "listening" to that particular channel at a given time, yet the 
5 sender of a message has no way to know this. Indeed, more channels of 
communication traffic mean more demands on the attentions of potential 
recipients, who, feeling besieged by the assault of e-mail, voice mail, pages, 
etc., may simply inactivate some communication devices at different times. 
Message senders, therefore, are faced with the choice of risking non-delivery 
10 of their messages, or painstakingly re-transmitting a message on every 
possible mode of communication modality. 

It may also be difficult to transmit the same message to multiple 
recipients. While a single e-mail message, sent once, can reach an unlimited 
number of destinations, phone messages must be repeated for each call. 
1 5 Moreover, different recipients may have access to different types of 

communication channels; perhaps some recipients can be reached efficiently 
only by e-mail, others by fax, and still others by page. 

The integration of communication input devices also raises the 
prospect of messages having multiple forms of content. Today, a single 
20 message may include input from a variety of sources (e.g., voice and text); 
transmitting such a message by traditional means may be quite cumbersome, 
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involving multiple separate transmissions that must be coordinated or difficult 
"packaging" of the different inputs into a single message. 

U.S. Serial No. 09/496,170, filed on February 1, 2000 and entitled 
Multi-Mode Message Routing and Management (the entire disclosure of 
5 which is hereby incorporated by reference) addresses these difficulties and 
discloses, inter alia, a facility for transmission of messages composed on one 
or more input devices to a single or multiple recipients by means of one or 
plural communication modalities. Such communication modalities may 
include, for example, conventional or wireless telephone, facsimile 

10 transmission, pager, e-mail, postal mail or courier. Thus, a message may be 
directed to a single recipient via multiple modalities, such as e-mail and fax, 
in order to ensure the earliest possible receipt of the message; or may be 
directed to multiple recipients by a single modality or by different modalities 
(e.g., some recipients receive the message by e-mail, others by fax, others 

15 by phone). The facility may be configured to respond to defined "escalation" 
rules that specify conditions under which different delivery modalities may be 
sequentially employed. For example, the rules may specify that if there is no 
response to an e-mailed question within an hour, the recipient is to be 
telephoned. Moreover, in addition to alternative transmission modalities, the 

20 escalation rules may specify alternative recipients (as well as alternative 

modalities for those recipients). The escalation rules may also specify default 
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contact methods, which may apply to specific individuals or to lists of 
recipients. 

The invention disclosed in the '170 application may include 
functionality for determining whether a message has been received (e.g., 
5 telephone and e-mail polling), as well as automatic sender notification upon 
confirmation of receipt. Moreover, in addition to monitoring messages in 
order to confirm their receipt, the invention may facilitate recipients' 
responses. In this way, the invention can orchestrate multi-question surveys 
utilizing multiple communication modes; for example, individuals contacted 
10 directly can respond immediately, while others can respond later in 

accordance with instructions delivered to them— e.g., via a web site or by 
calling a toll-free number. 

The invention disclosed in the '170 application supports messages 
having embedded questions that call for response by the recipient. Such 
1 5 responses, when received, may be communicated to the message sender 
and/or accumulated. 

Also facilitated by the invention disclosed in the '170 is scheduling of 
message delivery, on a mode-by-mode basis where appropriate. Scheduling 
may include delivery at a particular time or within a designated time window, 
20 or may involve preventing delivery during specified "black-out" periods. In 
some embodiments, scheduling may be automatic and based on 
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considerations such as the recipient's time zone and the form of 
communication (e.g., to avoid awakening the recipient by telephone). 

However, the '170 application contemplates a system in which 
customers' client computers communicate via the World Wide Web (the 
5 "web") with a server implementing the foregoing functions. In other words, 
the interaction is essentially manual and stepwise in nature, with customers 
selecting options and indicating preferences in an interactive session. This 
model is generally unsuited to business applications requiring more 
automated, high-volume access to messaging functions. 

10 

DESCRIPTION OF THE INVENTION 
Brief Summary of the Invention 

The present invention provides an application program interface (API) 
facilitating interaction, generally (although not necessarily) via the Internet, 
1 5 with a message-handling facility such as that disclosed in the '1 70 

application. In accordance with the invention, application programmers 
utilize a markup language (preferably XML-derived) to configure applications 
for compatibility and communication with the message-handling facility. The 
API is capable of processing high-volume requests for message routing, 


109140-4 


6 


status information, and various other functions on an automated basis, 
enabling businesses to make routine use of these functions. 

Indeed, the range of business-to-business and business-to-consumer 
organizations that can benefit from flexible messaging services is virtually 
5 limitless. For example, an airline may obtain contact information from 
passengers when tickets are purchased. Should a flight be delayed or 
cancelled, the airline can generate a single notification for transmission to all 
passengers via the messaging facility; as the flight time approaches, efforts 
to reach passengers not yet contacted can be intensified according to defined 

1 0 escalation rules. Similarly, a club or other organization can send out notices 
of meetings, receive confirmations and preferences from members, and alert 
them to changes using the messaging facility by means of the API. The 
message need be written and transmitted by the organization only once; all 
remaining operations, from bulk re-transmission to collecting and organizing 

1 5 responses, are performed automatically. 

In accordance with the invention, a message server comprising a 
plurality of modalities for transmitting messages is associated with an API. 
An application, typically implemented on a remote server, is configured to 
receive a message and a designation of one or more transmission modalities, 
20 and is further adapted for interaction with the API. The API comprises stored 
instructions supporting the interaction. Upon receiving the message and the 
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designation from the application server, the API causes the message server 
to transmit the message according to the designation. 


Brief Description of the Drawings 

5 The foregoing discussion will be understood more readily from the 

following detailed description of the invention, when taken in conjunction 
with the accompanying drawings, in which: 

FIG. 1 schematically represents the environment of the invention; and 

FIG. 2 schematically illustrates the components of the API and its 
10 mode of interaction. 


Detailed Description of the Preferred Embodiments 

7. Technical Context 

The functions of the messaging system are implemented by a server 
15 125, which may be realized as a single workstation or as a network of server 
computers, depending on the activity level and included functionality. For 
explanatory purposes, server 1 25 is represented as a single machine that 
includes a network interface 1 27 continuously connected to the Internet. 
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Network interface 127 and the other internal components of server 125 
intercommunicate over a main bidirectional bus 1 30 (which may be a 
physical bus in a single hardware device, or can instead represent a network 
such as a LAN or a WAN). The main sequence of instructions effectuating 
5 the functions of server 1 25 and facilitating interaction among customers, 
server 1 25, the Internet, and other modes of communication reside on a 
mass storage device (such as a hard disk or optical storage unit) 1 32 as well 
as in a main system memory 134 during operation. Execution of these 
instructions and effectuation of the functions of server 125 is accomplished 
10 by a central-processing unit ("CPU") 136. 

A group of functional modules that control the operation of CPU 1 36 
and perform the operations of server 1 25 is shown conceptually as located in 
system memory 1 34; once again, however, it should be stressed that this 
organization is for explanatory purposes. The various modules and servers 
1 5 may indeed be implemented as active processes running on a single machine, 
but functionality may instead be distributed among multiple machines (or 
processors within a single machine), once again depending on the activity 
level and included capabilities. 

An operating system 1 40 directs the execution of low-level, basic 
20 system functions such as memory allocation, file management, and operation 
of mass storage devices 132. At a higher level, a control block 142, 
implemented as a series of stored instructions, manages interaction among 
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the various functional components of the server and ensures proper routing 
of data thereamong. 

Although server 1 25 may be capable of communicating directly with 
customers by means of the web and electronic mail, as explained in the '170 
5 application, the present application is concerned primarily with hardware-to- 
hardware communications. Accordingly, an API 145 receives and processes 
communications from external sources, and transmits proper responses to 
those sources, via network interface 127. API 145 represents a 
programmatic interface for direct connection to appropriately configured 

10 third-party applications. The pattern of interaction with the external source, 
including the content of transmissions thereto, is handled by a transaction 
server 1 50. Transaction server 1 50 has access to various databases, 
collectively indicated at 1 52; these databases, discussed in greater detail 
below, are ordinarily stored on devices 132 and accessed as necessary. 

15 Depending on the requests received by API 145, transaction server 150 
causes messages to be assembled and transmitted to designated contacts, 
and retrieves and assembles information for transmission to outside inquiries. 
Credit-card validation and billing for services are handled by a billing server 
160. 

20 The various functions performed by server 125, which result in 

different patterns of interaction with customers, will now be described. 
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1. 1 Media Conversion and Basic Message Transmission 

A series of media servers, collectively indicated at 175, represent the 
interface servers that format messages for transmission; these messages 
may be in the form of voice, text (for transmission by e-mail, web or postal 
5 mail), or other desired format. Messages and media designations are 

received from remote applications via API 1 45, and once transaction server 
1 50 has received sufficient commands and content to fully specify a 
message (i.e., the message body, the recipient(s), desired delivery methods, 
and message options such as delivery scheduling and/or escalation rules), a 
10 message "job" is created and stored in a database 1 52. The job is passed to 
a job queue server 165, which is responsible for implementing and 
scheduling all message jobs. 

At this point, the message remains in the format in which it was 
generated. As noted previously, however, server 125 is capable of receiving 

1 5 messages, via the interface servers, in one format and transmitting them in a 
different, customer-selected format. The functions of media conversion and 
message assembly are performed by a series of message delivery servers, 
collectively illustrated at 167, dedicated thereto. The appropriate message 
delivery server 1 67 converts messages to the specified format and causes 

20 their transmission, via the designated communication medium, by means of a 
corresponding device driver selected from among a suite of drivers. The 
drivers operate a series of transmission devices, which include network 
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interface 1 27 for e-mail and/or web-based message delivery; a telephone 
interface 1 70 for message transmission by telephone, facsimile, pager, or 
handheld wireless device (although it should be noted that pager and wireless 
transmission can occur through network interface 127); and a document- 
5 generation module 172 for message transmission by postal mail or overnight 
courier. 

The timing of message transmission is governed by job queue server 
165. In response to the customer's authorization to send a message, job 
queue server 1 65 triggers the conversion and transmission operations just 
10 discussed. Job queue server 165 also contains (or, as shown for illustrative 
purposes, communicates with) a scheduling module 180, which can 
orchestrate transmission of messages at customer-specified times based on 
the computer's internal clock. 

Server block 1 65 may contain a text-to-speech conversion module, 
1 5 enabling customer-provided text to be transmitted by voice to the recipient 
by means of telephone interface 170. Conversely, telephony server 175 may 
be configured to respond to spoken customer commands, allowing the 
customer to compose and address a message by telephone (i.e., by 
communicating with server 125 by means of telephone interface 170). 

20 In still more complex operational modes, server 125 may facilitate 

catenation of message— either as separate segments of the same format, or 


109140-4 


12 


as segments encoded in different formats. In the case of audio messages, 
for example, a message delivery server 167 may append an audio "header" 
(typically a so-called "professional prompt") and a "trailer" to the customer's 
message. Thus, when the recipient answers the telephone, the header 
5 portion of the message may tell him that he is about to receive a message 
from the customer, and the trailer portion may facilitate response (as 
explained in further detail below). 

1.2 Confirming Message Receipt 

Any of a variety of techniques can be used to assess whether and 
10 when a message is received. Many e-mail systems natively support receipt 
confirmation. Alternatively, a URL can be embedded in the message; when 
the recipient receives the e-mail and clicks on this URL, receipt is 
automatically recorded. Moreover, the URL-specified web page may contain 
questions inviting response by the recipient, who thereupon transmits the 
1 5 web page back to server 1 25. 

Hard-copy deliveries can be tracked through the courier or by means of 
a follow-up telephone call to the recipient, while for telephone messages, the 
recipient can be asked to press a number to confirm receipt. In the context 
of telephone messages, it may be useful to detect whether a person or an 
20 answering machine has answered the phone. This determination can be 
used, for example, to select a proper audio header or even to choose 
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between alternative messages, which may differ depending whether the 
message is delivered to the recipient or a recording device; an answering 
machine, obviously, would not be asked to press a number to confirm 
receipt, nor would delivery typically be confirmed to the sender if the 
5 message was left on an answering machine. To implement answer 

detection, telephony server 147 is programmed to monitor the level of noise 
on the line once a connection is established, distinguishing between a 
"silence" noise level and a "speech" level. If an individual answers, he or 
she will typically issue a short greeting; that is, the signal pattern of a human 

10 answer is a short speech signal followed by silence. An answering machine, 
by contrast, will generally issue a long greeting ("Hello, you have reached the 
Smiths ..."). Based on the observed lengths of a sustained speech signal 
and an ensuing silence, telephony server 147 forms an initial guess as to 
whether a person or a machine has answered. If a person is guessed, 

1 5 telephony server 147 will play the audio header that prompts the answerer to 
press a touch-tone key, and if the proper touch-tone pulse is not detected, 
server 147 may revise its guess and assume that it is communicating with an 
answering machine. 

1.3 Message Scheduling 

20 It may not be appropriate to transmit messages by certain modes 

during particular time periods at the recipient's location. These "blackout" 
time periods may be established automatically by server 125, or may be 
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designated by the customer or the recipient. Via API 145, an external 
application may indicate blackout time periods for a particular message, or 
may permanently designate such periods for particular contacts (and 
particular communication modalities). Most commonly, permanently 
5 designated blackout periods are used to prevent messages from being sent 
by telephone or pager during times when the recipient is generally likely to be 
asleep or away from the communication modality. Message-specific 
blackout periods may be utilized by message senders familiar with the 
recipient's immediate schedule, or who do not wish to permanently establish 
10 blackout periods. 

Conversely, the external source may specify particular allowed time 
windows within which a message must be delivered. Once again, these may 
be established permanently for particular contacts or "on the fly" for specific 
messages. 

1 5 Time-zone scheduling may be employed automatically. For example, if 

the customer authorizes immediate message delivery at a time that would be 
late at night where the recipient is located, or schedules message delivery for 
such a time, transaction server 1 50 may cause the customer to be prompted 
with this information and asked to confirm or reschedule delivery. 

20 
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1.4 Escalation 

Rather than send a message to a prospective recipient redundantly via 
multiple communication modalities, transaction server 1 50 may be 
configured to allow the specification of escalation rules for sequential 
5 transmission as necessary. The external application selects a plurality of 
communication modalities and/or contacts, and criteria in the form of rules 
governing their use. Typically, an escalation rule will specify resort to a 
different communication modality (or a different recipient) if delivery of the 
message is not confirmed by a specified time, or within a specified period, 
10 using the current communication modality. 

Like scheduling restrictions, escalation rules may be defined 
permanently for a contact (and stored, along with " address book" 
information pertaining to that contact, in database 1 526) or may instead be 
defined for a particular message. Default message modalities and permanent 

1 5 escalation rules are particularly useful in the context of distribution lists, 
since the external application can simply enter a message and leave it to 
server 1 25 to deliver it to every person on a selected distribution list in 
accordance with each contact's escalation rules. On the other hand, 
message-specific escalation rules may be designated for particular messages 

20 transmitted to API 145. 
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To implement the escalation rules, the time period specified in a rule 
relevant to the initial message transmission is sent to scheduler 1 80. At the 
end of that time period following transmission, transaction server 1 50 
determines whether the message has been received in the manner described 
5 above. If not, the escalation rule (defined in database 1 526 or in the 

transaction record for the particular message) is executed, and the message 
re-transmitted by a different modality. If further escalation rules remain for 
the message, the appropriate time period is once again provided to scheduler 
180, and the flow sequence repeated. 

10 

2. An Exemplary Application Program Interface 

With reference to FIGS. 1 and 2, external sources such as a server 
190 generate requests for messaging functions and status information, and 
transmit these to server 1 25 via a computer network, such as the Internet, 

1 5 for processing. FIG. 2 illustrates in greater detail the role and basic 

components of API 145. Requests are actually generated by an application 
210 running as an active process on server 190. Application 210 formats 
these requests in the syntax allowed by API 145. Requests received by API 
145 from application 210 are analyzed by a parser 210, which interprets the 

20 request and causes the various server modules of server 1 25 to take 

appropriate action. The server modules may generate direct responses to the 
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requests or provide status information for transmission to application 210. A 
converter 220 places such information into statements conforming to the API 
syntax prior to transmission. 

Preferably, the API syntax conforms to the conventions of XML, using 
5 "tags" to characterize elements such as statements and field data. A tag 
surrounds the relevant element(s), beginning with a string of the form 
<tagname> and ending with </tagname>. Thus, parser 215 can be (or be 
based on) a conventional XML parser. 

The contents of a communication to or from API 1 45 take the form of 
10 a "document," which contains an identifying tag and either a "Request" (for 
documents generated by application 210) or a "Response" (for documents 
that API 145 returns to applications 210). Document elements are 
hierarchically organized into objects. Each object specifies the contents of 
fields associated with the object, and may also contain one or more nested, 
1 5 hierarchically inferior objects; this structure maintains the organization of 

information, facilitates movement of information in meaningful packages, and 
allows for re-use of information without explicit repetition. 

At the highest hierarchical level, "Super Objects" define the 
communication as a Request or a Response, and contain one or more "Major 
20 Objects." The Major Objects specify key functional elements of messaging 
activities, defining the relevant user accounts and the nature of the desired 
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message functions, and may contain sub-objects and/or entries for various 
fields within the Major Objects, Fields contain information, such as character 
strings or numbers, relevant to the objects containing them. 

The overall organization of a preferred implementation of API 1 45 
appears in summary form below; following the summary, the various objects 
and fields are described in greater detail. It should be understood that this 
API is illustrative only. 


I. Super Objects: contain required fields and one or more major objects 

A. Request (fields:) 

i) UserName 

ii) Password 

iii) Domain 

iv) OEMId 

v) OEMPassword 

vi) RequestType 

B. Response: same fields/objects as request + errors, warnings 

II. Major Objects: required elements of documents, may contain sub- 
objects and fields 

A. Member (fields:) 


Table 1 


Basic API Organization 


i) 
ii) 
iii) 


Command 
Id 

FirstName 
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iv) LastName 

v) Company 

vi) UserName 

vii) Password 

viii) AIlowNotices 

ix) Dialinld 

x) Dialin Password 

Member (subobjects:) 

i) Contact Method 

ii) Billing (fields: Id; Billing Plan; CurrentBalance) 

iii) Credit Card (fields you'd expect) 

B. Contact (subobjects:) 

i) Contact Method (fields:) 

a. Id 

b. Transport 

c. Qualifier 

d. Ordinal 

e. PhoneNum, FaxNum, PagerNum 

f. Access Code 

g. Email Address 

h. Street 1 

i. Street2 
j. Suite 

k. City 

I. State 

m. Zip 

n. Country 

ii) Contact MethodRef (fields:) 

a. Id 

b. FirstName, LastName, Company 

c. Transport, Qualifier, Ordinal 

d. AllowMultiple 

Contact (fields:) 

i) Command 

ii) Id 

iii) Prefix (optional) 
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iv) First Name, Middle Name, Last Name 

v) Company (optional) 

vi) Title (optional) 

C. Distribution List (fields:) 

i. Command (create, replace, append, delete, remove) 

ii. Name 

iii. Description 

iv. Id 

D. Job (fields:) 

i. Id 

ii. Charges 

Job (subobjects:) 

i. Message (fields:) 

A. Subject 

B. Template (optional) 

C. Id 

D. Date 

Message (subobjects:) 

A. MessageArg Objects: series of Name/Value tags: 


1) 

SENDER 

2) 

BODY 

3) 

ASK YESNO QUESTION 

4) 

QUESTION TO ASK 

5) 

EMAIL ADDR 


B. DeliveryTime Objects 

C. DeliveryTimeModifier Objects 

ii. Contact (to specify one-time recipient of message) 

iii. Delivery Request (elements:) 

A. DeliveryOptions field (in) 

B. Contact MethodRef sub-object 

Delivery Request (returned elements:) 
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A. ContactMethod 

B. Contact 

C. Delivery (fields:) 

1) Id 

2) Timestamp 

3) Duration 

4) Status (Not Sent, Sent, Failed, Cancelled, 
Cancel Pending) 

5) Details (Bad Address, Delivery Address is 
unreachable, No Answer, Busy, Answering 
Machine (assumed), Answering Machine, 
Maximum Delivery Attempts Exceeded, 
Acknowledged, Modem, Hangup, Callback 
Later, Internal Error 

6) Size 

7) Cost 

D. DeliveryRequest fields (out) 


1) 

Id 

2) 

EstDuration 

3) 

EstSize 

4) 

Status 

5) 

Details 

6) 

Completed 


E. Range (fields:) 

i. Object (i.e., type of object trying to look up) 


i. 

Type 

ii. 

Start 

v. 

End 
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Every transmission to API 1 45 requires a Request, which will generate 
a Response from API 145 (and the server modules with which it functions). 
The Request must identify one or more valid "members" by means of 
UserNames. A request contains the following required fields: 

5 Table 2: Request Fields 
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{In this and other tables, the In/Out column indicates whether the field 
is used in a Request (in), in a corresponding Response (out), or in both.) 

10 In addition to fields, the Request will generally contain one or more 

Major Objects. Typical actions include: send a message to specified 

109140-4 23 


recipients; add/edit/delete member, distribution list, contact information; look 
up the status of a job; send a billing inquiry. The following represents a 
typical Request (with the Contact Object, discussed in greater detail below, 
indicated but not actually specified): 


5 <Request> 

<UserName>RalphW< /UserName> 
<Password>abcl23</Password> 
<Domain>POETS</Domain> 
<OEMId>OEMId< /OEMId> 
1 0 <OEMPassword>OEMPassword</OEMPassword> 
<RequestType>validate</RequestType> 
[Contact Object] 
</Request> 


1 5 The Response is generally returned with the same objects that were 

included in the Request; if, however, the Request asks for information (e.g., 
a request for message status or for billing information), some objects or 
fields may be added or changed. In addition, the Response will contain 
Errors and Warnings fields as appropriate: 
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20 

Table 3: Errors and Warnings (Response Fields) 
Errors and Warnings are described in greater detail below. 
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The following represents a typical Response (with the Contact Object 


once again indicated but not actually specified): 

<Response> 

<UserName >RalphW< /UserName > 
5 <Password>abcl2 3</Password> 

<Domain>Poet s , Inc . < /Domain> 
<OEMId> OEMId</OEMId> 

<OEMPassword> OEMPassword</OEMPassword> 
<ResponseType>validate</ResponseType> 
1 0 <Errors>2< /Errors > 

<Warnings > 0 < /Warnings > 
[Contact Object] 
</Response> 

Requests and Responses specify one or more Major Objects as 
1 5 follows: 


Major Object 

Description 

Member 

User-level login that identifies a user account (end user or member) 

Contact 

Person or organization to which a message may be sent 

Distribution List 

A group of contact methods (for example, phone number, pager number, email 
address) to which a message may be sent 

Job 

Message to one or more contacts using one or more contact methods 

Range 

Used to look up other objects based on specific search criteria; for example, to 
look up a job by Id, or jobs sent on a certain date, or all contacts from the same 
organization 


Table 4: Major Objects 


Each Major Object contains zero or more fields and sub-objects, which 
may themselves contain additional sub-objects and/or fields. The various 
Major Objects will now be described in detail. 
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Major Objects— Member : generally an end user of the messaging 
service. 


Major Objects— Member— Fields : The Member object has the following 

fields: 




In/Out) 

Value s 
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AUowNotices 

Marks this member as being j 
interested in receiving receive '1 
pericyte taailings specific to this : ; 
domain 

In - 

"True" (to j 
allow): - 
otherwise, 1 
"False" ! 

<AllowNotices>true : 
</AllowJSTotices> : j 

Dailinld -vJ 

This is away fop the member to ; , : i 
identify himself when calling into i 
a voice response (automated 
touch tone telephone) system; j 

In 

Numeric 
string 


DiaEnPasswor 

d ;: : ... - 

Serves as a PIN for the voice , 
response system 

In 

Numeric 
string 

<DialinPas£word>l234 ; = - ■ , ;:; ! 
</DialinPassword> . ; 


Table 5: Member Major Object Fields 


Major Objects — Member — Sub-obiects : In addition, the Member 
object contains the following required sub-objects: 

5 Major Objects— Member— Sub-obiects— Contact Method : specifies 

communication mode (e-mail, telephone, etc.) and contact information (e-mail 
address, telephone number, etc.) specific thereto. Contact Method sub- 
objects are further described below in connection with the Contact Major 
Object. 

10 Major Objects— Member— Sub-obiects— Billing : specifies the billing 

plan and details necessary to bill the member (such as a credit-card number). 
The object also describes the current account status. The following table 
sets for the required fields for the billing sub-object: 
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Billing Plan 

Indicates which plan the mender is j 
using (pay-as-you-go, prepaid, both 
usinga credit card) 

In ! 


<BillingPlan>kkk33kkkk . 
</BillingPian> • • 

CuirentBalance : 

Currentbalance in US dollars as a [ 
floating point number i ; 1 

Out 


< currentBalanoe:>l 5 v 22 . 
</ ; Currentbalai?,ce> : ;: ■] 


Table 6 
Member Major Object 
Billing Sub-object 


5 The billing sub-object, in turn, contains a Credit Card sub-object, the 

fields for which are set forth in the following table: 
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Table 7 
Member Major Object 
Billing Sub-object 
5 Credit Card Sub-object 

The following is an example of entire Member Object: 


<Member> 

< Command> c r ea t e < / Command> 
<FirstName>Ralph</FirstName> 
1 0 <LastName>Emerson</LastName> 
<Company>Poets R Us</Company> 
<Us erName >RWE < /Us erName > 
<Password>MyPassword</Password> 
<DialinId>12345</DialinId> 
1 5 <DialinPassword>12345</DialinPassword> 

<ContactMethod> 

<Transport>email< /Transports 
<Qualifier>none< /Qualifier > 

<EmailAddress>ralph@Poets . com</EmailAddress> 
20 </ContactMethod> 

<ContactMethod> 

< Tr anspo r t >phone < / Transport > 
<Qualifier>office< /Qualifier > 

25 <Ordinal>0<Ordinal /Ordinal > 

< PhoneNum> 617-123-4567</ PhoneNum > 
< /ContactMethod> 

<Billing> 

<BillingPlan>kkk33kkkk<BillingPlan> 
30 <CurrentBalance>l . 00<CurrentBalance> 

<CreditCard> 

<FirstName>Ralph</FirstName> 
<MiddleName>Waldo</MiddleName> 
< La s t Name > Erne r s on < / La s t Name > 
35 <CreditCardType>Master 
Card< /CreditCardType> 

<CreditCardNumber>5123123412341233</Cre 
di t CardNumber > 

<ExpirationYear>2001</ExpirationYear> 
40 <ExpirationMonth>8</ExpirationMonth> 
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<StreetAddressl>1313 Mockingbird 
Lane < / S t r e e t Addr e s s 1 > 

<StreetAddress2>Poets R 
Us</StreetAddress2> 
5 <City>Warren</City 

<State>MA</State> 
<Zip>01810</Zip> 
< Conn try >USA< / Country 
</CreditCard> 
10 </Billing> 

< /Member > 

Major Objects — Contact : identifies an individual to whom a message 
may be sent. A Contact Object contains one or more Contact Method sub- 
objects (described below), each of which identifies a way to reach the 
15 individual. Contact and Contact Method information may or may not be 
stored in a member's Address Book (i.e., the a collection of a member's 
Contacts and their associated Contact Methods stored in database 1526). 
Thus, a Contact Major Object may be created to be stored in an Address 
Book, or for one-time use. 

20 Major Objects— Contact— Fields ; The Contact object has the following 

fields: 
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Table 8: Contact Major Object Fields 


Use of the Command field ensures that the Contact Object will be 
stored in the Address Book of the member with which it is associated. 
5 When the Contact Object is nested as a sub-object of a Job object (described 
below), the contact information will not be stored in an Address Book. 


The following represents a typical Contact Object (with Contact 
Method objects indicated but not actually specified): 


<Contact> 

1 0 <Pref ix>Mr . </Pref ix> 

<FirstName>William</FirstName> 
<MiddleName>L . </MiddleName> 
<LastName>Shakespeare</LastName> 
<Company>Globe Theater , Inc . < /Company > 

1 5 <Title>Director</Title> 

[ContactMethod Objects] 

< / Contact > 
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Maior Objects- Contact- Sub-obiects- Contact Method : as 


explained above, this object specifies the manner in which a member may be 
contacted. A Contact Method sub-object may contain some or all of the 
following fields: 
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Table 9: Contact Method Sub-object Fields 


To denote a member's primary e-mail address, for example, the 
following syntax is employed: 

5 <Contact Method> 

<transport>email</transport> 
<qualif ier>member</qualif ier> 
<EmailAddress>ralph@poets . com< /Email Address> 

10 

< /Contact Method> 

The following example illustrates addition of a new contact to an 
Address Book: 

1 5 <Contact> 

< Command >cr eat e< / Command > 

< Fir s tName >Albus < / Fi r s tName > 

< La s tName >Dumbl e do r e < /La s tName > 
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<Company>Hogwarts School for Witchcraft and Wizardry</ Company > 
<Ti tle>Headmaster< /Title> 

<ContactMethod> 

<Transport>phone< /Transport > 
5 <Qualif ier>cell</Qualif ier> 

< PhoneNum> 9785551234< / PhoneNum> 
< /ContactMethod> 

<ContactMethod> 

<Transport >pager < /Transport > 
1 0 <PagerNum>8885551234</PagerNum> 
<AccessCode>1030#</AccessCode> 
< /Contac tMethod> 

< /Contact > 


1 5 Maior Objects— Contact- Sub-obiects— Contact MethodRef : once a 

Contact Method has been created and stored, it may be referred to using a 
pointer called a Contact MethodRef. The pointer contains the Contact 
Method's Id, or a combination of fields that will uniquely identify that 
Contact Method. 


20 A Contact MethodRef sub-object may contain some or all of the 

following fields: 
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Table 10: Contact MethodRef Sub-object Fields 

Major Objects— Distribution List : a Distribution List is a grouping of 
Contact Methods. It allows a member to send a message to all of the 
5 Contact Methods in that list. A Distribution List object may contain some or 
all of the following fields: 
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Table 1 1 : Distribution List Major Object Fields 


In addition, the Distribution List object must have a list of Contact 
MethodRef sub-objects (i.e., pointers to already-created Contact Method 
objects). An exemplary Distribution List object is as follows: 

distribution List> 

<Command>append</Command 
<Name >Gryf f indor < /Name > 

<ContactMethodRef > 

<LastName>Potter</LastName> 

<Transport>email</Transport> 
< /ContactMethodRef > 

<ContactMethodRef > 

<Id>kkk3btkk</Id> 
< /ContactMethodRef > 

< /Distribution List> 

Major Objects— Job : a Job object contains a message to one or more 
Contacts using one or more Contact Methods, and contains sub-objects that 
define the specifics of the messaging task (e.g., the sender, the body of the 
message, recipients, etc.) A Job object also contains at least one Message 
sub-object (described below), and one or more Delivery Request or Contact 
sub-objects. 

A Job object contains only two fields, and these are specified only in a 
Response: 
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Table 1 2: Job Major Object Fields 

Maior Objects— Job— Sub-obiects— Message : the Message sub-object 
specifies the actual message. It includes fields and optional MessageArg 
5 Objects, and allows the requester to specify delivery times. 
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Table 13 
Job Major Object 
Message Sub-object Fields 


Major Objects— Job— Sub-objects— Message— MessaqeArg Sub- 
obiects : a Message object contains one or more MessageArg sub-objects 
that consist of a series of Name/Value tags according to the following 


10 syntax: 


<MessageArg> 

<Name > SENDER< /Name > 

< Value >Hermione Grainger < /Value > 
</MessageArg> 
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The optional MessageArg Name/Value tags are as follows: 



Values 


^-v-^: ...... : . ■ ^mm^ hi ^ ^ -mm 
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Table 14 

5 Job Major Object 

Message Sub-object 
MessageArg Sub-object Tags 

An exemplary Job Object is as follows: 

<Job> 

10 <Message> 

109140-4 39 


<Subject>Extra Quidditch Practice</Subject> 
<Template>generic</Template> 

<MessageArg> 

<Name >SENDER< /Name > 
5 <Value>01iver Wood< /Value > 

< /MessageArg> 


<MessageArg> 

<Name >BODY< /Name > 
<Value><! [CDATA [ 
10 I have scheduled an extra Quidditch 

practice session before the match with 
Slytherin. Be there Wednesday at 8:00AM sharp. 
]]> 
</Value> 
1 5 </MessageArg> 

<MessageArg> 

<Name >ASK_YESNO_QUESTION< /Name > 

< Value > YES < /Value > 
</MessageArg> 

20 <MessageArg> 

<NamexQUESTION_TO_ASK< /Name > 
< Value ><! [CDATA [ 

Can you make the practice session?] ] > 
< /Value > 
25 </MessageArg> 

<MessageArg> 

<Name >EMAIL_ADDR< /Name > 
<Value><! [CDATA [ 

wood@Hogwarts . edu] ] > 
30 </Value> 

< / Me s sageArg > 

</Message> 
<Contact> 


< Firs tName >Har ry< / Fi r s tName > 
35 <Las tName >Potter< /Las tName > 

< Cont actMethod> 

<Transport > email < /Transport > 

<EmailAddress>potter@hogwarts . edu< / Email Adddress> 
< / Contac tMe thod> 

40 < /Contact > 

<DeliveryRequest> 

<ContactMethodRef > 
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< La s tName > We a s 1 ey < / Las t Name > 
<Transport>email</Transport> 

< /ContactMe thodRef > 

< /De 1 i ve ryReque s t > 

5 </Job> 

Major Objects— Job— Sub-obiects— Delivery Request : the Delivery 
Request sub-object allows the requester to specify a recipient for a job, as 
well as to specify delivery options (as fields within the sub-object). The 
Delivery Request Object may contain a Contact MethodRef sub-object (to 
10 refer to a previously created contact method for the recipient) or may instead 
refer to a Contact sub-object of a Job object (for one-time use of that 
Contact/Contact Method). 

An exemplary Delivery Request sub-object is as follows: 

<DeliveryRequest> 

1 5 < ContactMe thodRef > 

<LastName>Potter</LastName> 
<Transport>email</Transport> 
<Qual i f ier >home < /Qual i f i er > 

< /ContactMe thodRef > 

20 < /De 1 i ve r yRe que s t > 

The Delivery Request sub-object is also returned by API 1 45 as a 
Response. Furthermore, when an existing Job object is retrieved using a 
Range object lookup (described below), that job's Delivery Requests are also 
returned. 

25 The Delivery Request sub-object may contain the following fields: 
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Table 1 5 
Job Major Object 
Delivery Request Sub-object Fields 

5 


An exemplary Delivery Request Response is as follows: 


<Del iveryReques t > 

<ID>kztubkkkk</ID> 
<EstDuration>8 0</EstDuration> 
10 <Status>Not Sent</Status> 

<DeliveryOpt ions>Standard< /Delivery-Options > 
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<Completed>false</Completed> 
<ContactMethod> 

<ID>kit5bkkuk</ID> 
<Transport>phone< /Transport > 
5 <Qualif ier>of f ice</Qualif ier> 

<Unreachable>false</Unreachable> 
<EmailAddress>potter@hogwarts . edu</E 
mailAddress> 

< /Contac tMethod> 

1 0 <Contact> 

< ID>kk3 6bkkkk< / ID> 

<Pref ixx/Pref ix> 

<FirstName>Harry</FirstName> 

< Mi ddl eName > < /Mi ddl eName > 

1 5 <LastName>Potter</LastName> 

<Company>Hogwarts School for 
Witchcraft and Wizardry^/ Company > 
<Title>Student</Title> 

< OneTime > t rue < / OneTime > 

20 < /Contact > 

< /De 1 i ve r yRe que s t > 

Maior Objects— Job— Sub-obiects— Delivery Request— Delivery Sub- 
object : the Delivery sub-object never appears in a Request. It is returned by 
25 API 145 as a sub-object of a Delivery Request object when a Range object 
lookup (see below) is performed on a job. 


The Delivery sub-object may contain the following fields: 
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Job Major Object 
Delivery Request Sub-object 
Delivery Sub-object Fields 


5 Major Objects— Range : The Range object facilitates retrieval of a list 

of objects based on specified criteria. In particular, the Range object can 
retrieve Distribution List, Job, and Contact objects. The Response to a 
Range object returns the requested objects. 

The Range Major Object may contain the following fields: 


Allowed Values 


Specifies'tnl'type of obje<§yx>if 


!!iltjit> 
111 





Distribtitlfoftkist "** * ; 


SB 


Z>miuZZ*Z 


3^\\ZAz 


pisitribution »Jtif>£ i ' '- s f? 


■Slip 
lite. 


Ail (return all Jobs for feiiiSI- 

LastName (looKupfbyj t :'!!2X 

Company (lookup by „ 

All (return allCokactsfbrMiisS' 



109140-4 


46 


Start .j 

Specifies criteriaforthedata you 
are looking up; depends on the j 
value of;<Type> : ) 

in 

String ; . ! 

If <Type>LastName</Type>: j 

Then, ' -:i 
<S:tart>Po.tter</Start> ; 

If <Type>Date< /Type > :: v > 

Then, <sta£t>2000 : 02 : 14 1 

12::30:00</Start> . 'j 

End 

Specifies the end of a date range; 
only used if the value of ; : J 
<Type> is "Dafe" 

in : 

yyyy:mm:dd hh;mm;s^ 

12:35:00 </End> i ;- : ' j 


Table 17 
Range Major Object Fields 


5 The Range object is always included in a Request object, with the 

value of the RequestType set to "lookup." The most common use for the 
Range object is to look up a Job object by Id, for example, 

<Range> 

1 0 <Object>job</Object> 
<Type > Id< /Type > 
<Start>kkky5btk</Start> 

< Range > 

15 

Error Handling : Errors fall into three classes: parsing errors, fatal 
errors, and errors/warnings encountered while validating any object or field. 

Parsing errors occur when the input XML tags do not conform to XML 
specifications. Typical examples of malformed XML code include tags that 
20 are not closed and illegal characters; to avoid the latter type of error, free- 
form text should be enclosed within CDATA tags. When parsing errors are 
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encountered, API 1 45 returns a ParseErrors object, which contains one or 
more sub-objects called ParseError and having the following fields: 


Fields 1 

Description ] 

In /6ut ! 

Allowed | 
Values 

Example 

ErrorString j 

Text explaining the error j 

Out : E 

String 

<ErrorString>^xpecting ' j 

V:ai name '■>"' found : . : ;: : . ; ! 
^?,\</ErrorStririg> 

LineNumber 

Line number where error found s 

Otlt 

Integer •• 

<LineNumber > 0 ; ,: r ' 

< /LirieHumbar>" - : " j 


5 Table 1 8 

ParseError Sub-object Fields 


An example is as follows: 

<ParseErrors> 
1 0 <ParseError> 

<ErrorString>Expecting 'a name'; found , /ErrorString> 
<LineNumber>9</LineNumber> 
</ParseError> 
</ParseErrors> 

1 5 A fatal error signifies a significant problem encountered in the course 

of processing a Request. API 145 returns a FatalError object with a single 
field (ErrorString), which indicates the nature of the error. For example, 

<FatalError> 

<ErrorString>User Transaction Server Unavailable . </ErrorString> 
20 </FatalError> 
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Validation errors and warnings are attached to problematic objects or fields 
as "attributes." The Errors and Warnings fields of a Response object contain 
the following information: 


Fields I 

Description 

In/Oiut 

Allowed 
Values 

Example 

Errors ; : j 

Set to the number of errors, discovered 
while processing the major objects; f 
included in the Request ; ; ;i ; j 

Out 

Unsigned : 
integer 

<Errors>2 ?: /Errors> ; [ 

Warnings 

Set to the number ofwarnings (a less 
severe error) discovered while ; 
processing the major objects included in 
the Request ! •• ; • J 

Out ; 

Unsigned ; : 
integer 

<War?iirigs>i</Warnings> 


5 Table 1 9 

Response Super Object 
Errors and Warnings Fields 


For example, if a Request contains an invalid telephone number, a 
10 warning attribute will be attached to the problematic <PhoneNum> field. If 
a Request fails to provide a Billing sub-object when trying to add a Member, 
an error attribute will be attached to the Member object. 

It will therefore be seen that the foregoing represents a full-featured 
messaging system capable of operating in multiple communication modes 
1 5 and interacting with remote applications through a common, extensible 

interface. The terms and expressions employed herein are used as terms of 
description and not of limitation, and there is no intention, in the use of such 
terms and expressions, of excluding any equivalents of the features shown 
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and described or portions thereof, but it is recognized that various 
modifications are possible within the scope of the invention claimed. 

What is claimed is: 


O 

s 

m 
m 

m 
m 

o 
si 
nj 

O 

o 
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CLAIMS 


1 1 . A messaging system comprising: 

2 a. a message server comprising a plurality of modalities for 

3 transmitting messages, the message server being responsive to a 

4 remote application configured to generate a message and a 

5 designation of at least one of the transmission modalities, the 

6 message server communicating with the application via a computer 

7 network; and 

8 b. an application program interface (API) comprising stored instructions 

9 executing on the message server, the API receiving the message 

10 and designation from the application and causing the message 

1 1 server to effect transmission of the message according to the 

12 designation. 
13 

1 2. The system of claim 1 wherein the API is configured to interpret XML 

2 syntax, the message and the designation being expressed as a request 

3 formatted in XML syntax. 
4 

1 3. The system of claim 1 wherein the message server comprises a database 

2 for storing contact data, the API being configured to process a request from 
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3 the application to establish a database record specifying a member and 

4 contact data for the member, the contact data including at least one contact 

5 method specifying a transmission modality and data facilitating contact of 

6 the member via the specified transmission modality, the API causing the 

7 message server to send the message in accordance with the contact data. 
8 

1 4. The system of claim 1 wherein the message server comprises a database 

2 for storing contact data for a plurality of members, the API being configured 

3 to process a request from the application to (i) access an existing database 

4 record specifying a member and contact data for the member, the contact 

5 data including at least one contact method specifying a transmission 

6 modality and data facilitating contact of the member via the specified 

7 transmission modality, or (ii) obtain contact data from the application for a 

8 non-member, the API causing the message server to send the message in 

9 accordance with the contact data. 
10 

1 5. The system of claim 4 wherein the API is further configured to process a 

2 request from the application to create a distribution list comprising a plurality 

3 of the existing database records, the API causing the message server to send 

4 the message to the members in the distribution list in accordance with the 

5 contact data. 
6 
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1 6. The system of claim 4 wherein the existing database record comprises a 

2 plurality of contact methods, the API being further configured to process a 

3 request from the application specifying at least one of the contact methods, 

4 the API causing the message server to send the message to the member in 

5 accordance with the at least one specified contact method. 
6 

1 7. The system of claim 1 wherein the API is further configured to respond to 

2 status requests from the application, the API returning, in response to a 

3 status request specifying a messaging task, status information pertinent to 

4 the messaging task. 
5 

1 8. The system of claim 7 wherein the status information includes a status 

2 designation for the message, the status designation specifying (i) whether 

3 the message has been sent, (ii) whether the message was successfully 

4 received, (iii) whether the message failed, and (iv) whether the message has 

5 been cancelled. 
6 

1 9. The system of claim 8 wherein, for each failed message, the API returns 

2 an explanation for the failure. 
3 

1 10. The system of claim 1 wherein the message is addressed to at least one 

2 contact, the message comprising a question, the API causing the message 

3 server to pose the question to the at least one contact. 
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4 

1 11. The system of claim 1 0 wherein the API is further configured to respond 

2 to status requests from the application, the API returning, in response to a 

3 status request specifying the message, status information pertinent to the 

4 message including any response to the question by the at least one contact. 
5 

1 1 2. The system of claim 1 wherein the API is configured to handle 

2 information in the form of objects, the objects including (i) member objects 

3 designating member information for a plurality of potential recipients of the 

4 message, (ii) contact objects specifying information facilitating 

5 communication with the potential recipients in accordance with a plurality of 

6 transmission modalities, (iii) job objects specifying messages and 

7 characteristics thereof, and (iv) delivery objects specifying modes of message 

8 delivery, the application providing the message and the designation in object 

9 form. 
10 

1 13. For use in conjunction with a message server comprising a plurality of 

2 modalities for transmitting messages and an interface for communicating 

3 with remote applications via a computer network, an application program 

4 interface (API) comprising stored instructions executing on the message 

5 server, the API being responsive to application-originated requests comprising 

6 a message and a designation of at least one of the transmission modalities, 


109140-4 


54 


7 the API causing the message server to effect transmission of the message 

8 according to the designation. 
9 

1 14. The API of claim 13 wherein the executing instructions interpret XML 

2 syntax, the message and the designation being expressed as a request 

3 formatted in XML syntax. 
4 

1 1 5. The API of claim 13 wherein the message server comprises a database 

2 for storing contact data, the API being configured to process a request from 

3 the application to establish a database record specifying a member and 

4 contact data for the member, the contact data including at least one contact 

5 method specifying a transmission modality and data facilitating contact of 

6 the member via the specified transmission modality, the API causing the 

7 message server to send the message in accordance with the contact data. 
8 

1 1 6. The API of claim 1 3 wherein the message server comprises a database 

2 for storing contact data for a plurality of members, the API being configured 

3 to process a request from the application to access an existing database 

4 record specifying a member and contact data for the member, the contact 

5 data including at least one contact method specifying a transmission 

6 modality and data facilitating contact of the member via the specified 

7 transmission modality, the API causing the message server to send the 

8 message in accordance with the contact data. 
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1 17. The API of claim 16 wherein the API is further configured to process a 

2 request from the application to create a distribution list comprising a plurality 

3 of the existing database records, the API causing the message server to send 

4 the message to the members in the distribution list in accordance with the 

5 contact data. 
6 

1 18. The API of claim 16 wherein the existing database record comprises a 

2 plurality of contact methods, the API being further configured to process a 

3 request from the application specifying at least one of the contact methods, 

4 the API causing the message server to send the message to the member in 

5 accordance with the at least one specified contact method. 
6 

1 1 9. The API of claim 1 3 wherein the executing constructions are configured 

2 to respond to status requests from the application, the API returning, in 

3 response to a status request specifying a messaging task, status information 

4 pertinent to the messaging task. 
5 

1 20. The API of claim 19 wherein the status information includes a status 

2 designation for the message, the status designation specifying (i) whether 

3 the message has been sent, (ii) whether the message was successfully 

4 received, (iii) whether the message failed, and (iv) whether the message has 

5 been cancelled. 
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1 21 . The API of claim 20 wherein, for each failed message, the API is 

2 configured to return an explanation for the failure. 
3 

1 22. The API of claim 1 3 wherein the message is addressed to at least one 

2 contact, the message comprising a question, the API causing the message 

3 server to pose the question to the at least one contact. 
4 

1 23. The API of claim 22 wherein the executing instructions are configured to 

2 respond to status requests from the application, the API returning, in 

3 response to a status request specifying the message, status information 

4 pertinent to the message including any response to the question by the at 

5 least one contact. 
6 

1 24. The API of claim 1 3 wherein the executing instructions are configured to 

2 handle information in the form of objects, the objects including (i) member 

3 objects designating member information for a plurality of potential recipients 

4 of the message, (ii) contact objects specifying information facilitating 

5 communication with the potential recipients in accordance with a plurality of 

6 transmission modalities, (iii) job objects specifying messages and 

7 characteristics thereof, and (iv) delivery objects specifying modes of message 

8 delivery, the application providing the message and the designation in object 

9 form. 
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1 25. A method of handling and transmitting messages to recipients, the 

2 method comprising the steps of: 

3 a. providing a message server comprising a plurality of modalities for 

4 transmitting messages, the message server being responsive to a 

5 remote application configured to generate a message and a 

6 designation of at least one of the transmission modalities; 

7 b. causing the message server to communicate with the application 

8 via a computer network; and 

9 c. providing an application program interface (API) comprising stored 

1 0 instructions executing on the message server, the API receiving the 

1 1 message and designation from the application and causing the 

1 2 message server to effect transmission of the message according to 

13 the designation. 
14 

1 26. The method of claim 25 wherein the API is configured to interpret XML 

2 syntax, the message and the designation being expressed as a request 

3 formatted in XML syntax. 
4 

1 27. The method of claim 25 further comprising the step of providing a 

2 database for storing contact data, the server processing a request from the 

3 application to establish a database record specifying a member and contact 

4 data for the member, the contact data including at least one contact method 
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5 specifying a transmission modality and data facilitating contact of the 

6 member via the specified transmission modality, the server sending the 

7 message in accordance with the contact data. 
8 

1 28. The method of claim 25 further comprising the step of providing a 

2 database for storing contact data for a plurality of members, the server 

3 processing a request from the application to access an existing database 

4 record specifying a member and contact data for the member, the contact 

5 data including at least one contact method specifying a transmission 

6 modality and data facilitating contact of the member via the specified 

7 transmission modality, the server sending the message in accordance with 

8 the contact data. 
9 

1 29. The method of claim 28 further comprising the steps of (i) processing a 

2 request from the application to create a distribution list comprising a plurality 

3 of the existing database records, and (ii) sending the message to the 

4 members in the distribution list in accordance with the contact data. 
5 

1 30. The method of claim 28 wherein the existing database record comprises 

2 a plurality of contact methods, the request from the application specifying at 

3 least one of the contact methods, the message server sending the message 

4 to the member in accordance with the at least one specified contact method. 
5 
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1 31 . The method of claim 25 further comprising the step of responding to 

2 status requests from the application, the server returning, in response to a 

3 status request specifying a messaging task, status information pertinent to 

4 the messaging task. 
5 

1 32. The method of claim 32 wherein the status information includes a status 

2 designation for the message, the status designation specifying (i) whether 

3 the message has been sent, (ii) whether the message was successfully 

4 received, (iii) whether the message failed, and (iv) whether the message has 

5 been cancelled. 
6 

1 33. The method of claim 32 wherein, for each failed message, the server 

2 returns an explanation for the failure. 
3 

1 34. The method of claim 25 wherein the message is addressed to at least 

2 one contact, the message comprising a question, the message server posing 

3 the question to the at least one contact. 
4 

1 35. The method of claim 34 wherein server responds to status requests from 

2 the application, the server returning, in response to a status request 

3 specifying the message, status information pertinent to the message 

4 including any response to the question by the at least one contact. 
5 
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1 36. The method of claim 25 wherein the API is configured to handle 

2 information in the form of objects, the objects including (i) member objects 

3 designating member information for a plurality of potential recipients of the 

4 message, (ii) contact objects specifying information facilitating 

5 communication with the potential recipients in accordance with a plurality of 

6 transmission modalities, (iii) job objects specifying messages and 

7 characteristics thereof, and (iv) delivery objects specifying modes of message 

8 delivery, the application providing the message and the designation in object 

9 form. 
10 
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1 ABSTRACT 

2 Transmission of messages composed on one or more input devices to 

3 a single or multiple recipients by means of one or plural communication 

4 modes is facilitated. Such communication modes may include conventional 

5 or wireless telephone, facsimile transmission, pager, e-mail, postal mail or 

6 courier. An application program interface (API) mediates between remote 

7 applications requesting messaging functions and a message server that 

8 actually implements these functions. The API is capable of processing high- 

9 volume requests for message routing, status information, and various other 

10 functions on an automated basis, enabling businesses to make routine use of 

1 1 these functions. 
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